EKSでArgo CDのチュートリアルを試してみた
はじめに
おはようございます､加藤です｡GitOpsという言葉は聞いた事があるでしょうか？ Weaveworksが提唱する運用・CDの手法で､GitをインフラストラクチャのSingle Source of Truth(信頼できる唯一の情報源)として扱い､変更の承認はプルリクエストで行うというものです｡ 運用経験がある訳でもないので浅い理解ですが､下記のように捉えています｡
- インフラストラクチャを宣言的に管理
- Gitからインフラストラクチャへ同期し続ける
- Pull型アーキテクチャ
今回は､KubernetesでGitOpsを実現するツールのArgo CDをAmazon EKSで検証してみました｡
やってみた
ドキュメントのGetting Startedを参考に進めて行きます｡
環境情報
| 項目 | 値 |
|---|---|
| Kubernetesバージョン | 1.11 |
| プラットフォームバージョン | eks.2 |
kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-12-06T01:33:57Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.8-eks-7c34c0", GitCommit:"7c34c0d2f2d0f11f397d55a46945193a0e22d8f3", GitTreeState:"clean", BuildDate:"2019-03-01T22:49:39Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
ネームスペースの作成
Argo CDをデプロイするネームスペースを作成します｡
kubectl create namespace argocd
マニフェストファイルの編集に関して
Argo CDのGitHub Release v1.0.0を確認すると､kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.0.0/manifests/install.yamlでデプロイするQuick Start手順が紹介されています｡(Getting Startedの方法は古いようです)
ダウンロードして中身を確認すると､一行目に # This is an auto-generated file. DO NOT EDIT と記載されており､これを直接編集すべきで無いことがわかります｡
プロダクション環境では､ドキュメントのDeclarative Setup及び､リポジトリの､argo-cd/hack/update-manifests.shからKustomizeを使いマニフェストを生成することがわかります｡ 今回は簡易検証なので､マニフェストファイルを直接編集します｡
マニフェストファイルのダウンロード
マニフェストをローカルに保存します｡
curl -O [https://raw.githubusercontent.com/argoproj/argo-cd/v1.0.0/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/v1.0.0/manifests/install.yaml)
初回デプロイ
ひとまず､デプロイしてみます｡
kubectl -n argocd apply -f install.yaml
パスワードの取得
Argo CDデフォルトでローカルユーザーadminが作成されます｡パスワードはargocd-serverのPod名なので確認します｡
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2
ちなみに､ローカルユーザーは追加作成できません｡SSO環境を作成する必要があります｡ SSO Configuration - Argo CD - Declarative GitOps CD for Kubernetes
Webアクセス
Argo CDにアクセスするには､下記の3つの方法があります｡
- Service Type Load Balancer
- Ingress
- Port Forwarding
今回はPort Forwardingで接続します｡
kubectl port-forward svc/argocd-server -n argocd 8080:443
Webブラウザで､http://localhost:8080にアクセスします｡HTTPSにリダイレクトされ､ログイン画面にたどり着けました｡リダイレクト後に証明書エラーが発生しますが接続を続行してください｡
admin/先程取得したPod名でログインします｡
CLIアクセス
CLIツールをインストールします｡ポートフォワーディングを維持する必要があるので､別ターミナルを開き作業してください｡
brew tap argoproj/tap brew install argoproj/tap/argocd
ログインします｡証明書エラーを回避する為に--insecureを指定しています｡指定しない場合は､対話型で続行を確認されます｡
argocd login --insecure localhost:8080 Username: admin Password: 'admin' logged in successfully Context 'localhost:8080' updated
パスワードを更新し､再ログインします｡
argocd account update-password *** Enter current password: *** Enter new password: *** Confirm new password: Password updated argocd login --insecure localhost:8080 Username: admin Password: 'admin' logged in successfully Context 'localhost:8080' updated
HTTPアクセス
Argo CDにHTTPアクセスすると､HTTPSにリダイレクトされます｡これはIngressでALB経由でアクセスさせる際に問題になりそうです｡ HTTPの許可を調査・検証してみます｡
Deploymentのargocd-serverに--insecureオプションを与えれば良いみたいです｡install.yamlの2040行目の後ろに追記します｡
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/component: server
app.kubernetes.io/name: argocd-server
app.kubernetes.io/part-of: argocd
name: argocd-server
spec:
selector:
matchLabels:
app.kubernetes.io/name: argocd-server
template:
metadata:
labels:
app.kubernetes.io/name: argocd-server
spec:
containers:
- command:
- argocd-server
- --staticassets
- /shared/app
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/component: server
app.kubernetes.io/name: argocd-server
app.kubernetes.io/part-of: argocd
name: argocd-server
spec:
selector:
matchLabels:
app.kubernetes.io/name: argocd-server
template:
metadata:
labels:
app.kubernetes.io/name: argocd-server
spec:
containers:
- command:
- argocd-server
- --staticassets
- /shared/app
- --insecure
ポートフォワーディングを解除して､更新を適用します｡更新が完了したら再度ポートフォワーディングで接続しますが､今度は443を80に変更して実行してください｡
kubectl apply -n argocd -f install.yaml kubectl port-forward svc/argocd-server -n argocd 8080:80
ブラウザでアクセスし､HTTPSにリダイレクトされない事を確認できました｡
Ingress Configuration - Argo CD - Declarative GitOps CD for Kubernetes
しかし､ドキュメントにはALBはHTTP2/gRPCに完全対応していないので使えないという記載があります｡
AWS Application Load Balancers (ALBs) And Classic ELB (HTTP Mode) Neither ALBs and Classic ELB in HTTP mode, do not have full support for HTTP2/gRPC which is the protocol used by the argocd CLI. Thus, when using an AWS load balancer, either Classic ELB in passthrough mode is needed, or NLBs.
一方で､v0.12のリリース情報ではgRPC-Web (HTTP1.1)をサポートしたので､どんなロードバランサー､Ingress､API Gatewayでも動作すると記載されいます｡
Argo CD v0.12 Released – Argo Project
gRPC-Web Support The CLI is now able to communicate to the Argo CD API server using gRPC-Web (HTTP1.1) using a new CLI flag
—grpc-web. This resolves some compatibility issues with ingresses and gRPC (HTTP2), and should enable the argocd CLI to work with virtually any load balancer, ingress controller, or API gateway.
これより先は､プロダクション向けにArgo CDを検証する際に調べて見ようと思います｡
ブラウザキャッシュのクリア
最初はHTTPSでつないでログインしていた状態からHTTPに変更した影響なので､ログインが正常に進まない状態になりました｡(ログインを実行すると失敗にならず､ログイン画面にリダイレクトされる) Cookieを消すと正常に戻りました｡同様の症状にかかった場合はお試しください｡
サンプルアプリのデプロイ
Argo CDはマニフェストファイルを定義する為に､以下の5つの方法に対応しています｡
- Kustomize applications
- Helm charts
- Ksonnet applications
- A directory of YAML/JSO/Jsonnet manifests
- Any custom config management tool configured as a config management plugin
Pluginsは柔軟な機能で､指定したバイナリを実行する事が可能です｡Helm + Kustomizeといった使い方や､バンドルされていないツールをCustom Toolで追加して使用する事が可能です｡
今回は､KustomizeによるYAMLマニフェストファイルによるデプロイを試してみます｡NEW APPLICATIONをクリックして､新規アプリを設定します｡
GENERAL
| 項目 | 値 | 説明 |
|---|---|---|
| Application Name | gusetbook-kustomize | Argo CDでアプリを管理するための識別名 |
| Project | default | Argo CD内でアプリ |
| Sync-policy | Automatic with automatic pruning | Gitリポジトリとの同期方法 |
SOURCE
| 項目 | 値 | 説明 |
|---|---|---|
| Repository URL | https://github.com/argoproj/argocd-example-apps.git | アプリのGitリポジトリ |
| Revision | HEAD | リポジトリのリビジョン |
| Path | kustomize-guestbook | リポジトリ内のファイルを配置しているディレクトリ |
DESTINATION
| 項目 | 値 | 説明 |
|---|---|---|
| Cluster URL | https://kubernetes.default.svc | デプロイ先のk8sクラスタ |
| NameSpace | default | デプロイ先のk8s名前空間 |
| Sync-policy | Automatic with automatic pruning | Gitリポジトリとの同期方法 |
Kustomize
| 項目 | 値 | 説明 |
|---|---|---|
| Name Prefix | argocd-sample- | k8sリソースに付与するプレフィックス |
作成したアプリはカード形式で表示されました｡クリックすると詳細画面へ進みます｡
リソースが可視化されています､とても見やすいです｡
各リソース毎の詳細が確認でき､EDIT機能によってマニフェストファイルを編集(kubectl edit相当)することや､Podのログを見る事ができます｡
EDIT機能で､Deployment: argocd-sample-guestbook-uiのレプリカ数を変えてみました｡1個→2個への変更です｡
Diffの表記は一瞬混乱しましたが､現在の状態が左側でGitリポジトリが右側です｡今の状態にGitリポジトリの状態を適用するとどう変化するかをDiffで見る形です｡
DELETE機能でDeployment: argocd-sample-guestbook-uiを削除します｡
配下のリソースを含めて削除されました｡また､リポジトリと差が発生している状態はOutOfSyncとステータスが表示されます｡
現在､自動同期の設定ですが､Argo CDから行った変更に対しては自動で再同期がかかることはありませんでした｡
Automated Sync Policy - Argo CD - Declarative GitOps CD for Kubernetes
自動同期のドキュメントを確認すると､同じコミットハッシュに対しては一度しか自動同期が実行されないと記載されているので仕様どおりのようです｡
アプリケーションの削除
リソースが残っている状態で､アプリケーションを削除してみます｡
kubectlで確認するとリソースも削除されていました!!
あとがき
Argo CDの基本的な機能を触ってみました｡UIが美しく設定も直感的でした｡詰まったところとしては､ユーザーの作成方法やHTTP接続あたりです｡ 次回は､HAで構成でプロダクションに耐える形でのデプロイ方法を調査・検証してみようと思います｡
